jira LE-4321
cve CVE-2023-53125
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Szymon Heidrich <[email protected]>
commit d8b2283

Packet length retrieved from skb data may be larger than
the actual socket buffer length (up to 9026 bytes). In such
case the cloned skb passed up the network stack will leak
kernel memory contents.

Fixes: d0cad87 ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver")
	Signed-off-by: Szymon Heidrich <[email protected]>
	Signed-off-by: David S. Miller <[email protected]>
(cherry picked from commit d8b2283)
	Signed-off-by: Jonathan Maple <[email protected]>

…in skb_pull

jira LE-4321
cve CVE-2023-53125
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Szymon Heidrich <[email protected]>
commit 43ffe6c

Packet length check needs to be located after size and align_count
calculation to prevent kernel panic in skb_pull() in case
rx_cmd_a & RX_CMD_A_RED evaluates to true.

Fixes: d8b2283 ("net: usb: smsc75xx: Limit packet length to skb->len")
	Signed-off-by: Szymon Heidrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit 43ffe6c)
	Signed-off-by: Jonathan Maple <[email protected]>

jira LE-4321
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Christoph Hellwig <[email protected]>
commit 35dc55b

If xfs_bmapi_write finds a delalloc extent at the requested range, it
tries to convert the entire delalloc extent to a real allocation.

But if the allocator cannot find a single free extent large enough to
cover the start block of the requested range, xfs_bmapi_write will
return 0 but leave *nimaps set to 0.

In that case we simply need to keep looping with the same startoffset_fsb
so that one of the following allocations will eventually reach the
requested range.

Note that this could affect any caller of xfs_bmapi_write that covers
an existing delayed allocation.  As far as I can tell we do not have
any other such caller, though - the regular writeback path uses
xfs_bmapi_convert_delalloc to convert delayed allocations to real ones,
and direct I/O invalidates the page cache first.

	Signed-off-by: Christoph Hellwig <[email protected]>
	Reviewed-by: "Darrick J. Wong" <[email protected]>
	Signed-off-by: Chandan Babu R <[email protected]>
(cherry picked from commit 35dc55b)
	Signed-off-by: Jonathan Maple <[email protected]>

jira LE-4321
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Christoph Hellwig <[email protected]>
commit 6773da8
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-4.18.0-553.76.1.el8_10/6773da87.failed

xfs_bmapi_write can return 0 without actually returning a mapping in
mval in two different cases:

 1) when there is absolutely no space available to do an allocation
 2) when converting delalloc space, and the allocation is so small
    that it only covers parts of the delalloc extent before the
    range requested by the caller

Callers at best can handle one of these cases, but in many cases can't
cope with either one.  Switch xfs_bmapi_write to always return a
mapping or return an error code instead.  For case 1) above ENOSPC is
the obvious choice which is very much what the callers expect anyway.
For case 2) there is no really good error code, so pick a funky one
from the SysV streams portfolio.

This fixes the reproducer here:

    https://lore.kernel.org/linux-xfs/CAEJPjCvT3Uag-pMTYuigEjWZHn1sGMZ0GCjVVCv29tNHK76Cgg@mail.gmail.com0/

which uses reserved blocks to create file systems that are gravely
out of space and thus cause at least xfs_file_alloc_space to hang
and trigger the lack of ENOSPC handling in xfs_dquot_disk_alloc.

Note that this patch does not actually make any caller but
xfs_alloc_file_space deal intelligently with case 2) above.

	Signed-off-by: Christoph Hellwig <[email protected]>
	Reported-by: 刘通 <[email protected]>
	Reviewed-by: "Darrick J. Wong" <[email protected]>
	Signed-off-by: Chandan Babu R <[email protected]>
(cherry picked from commit 6773da8)
	Signed-off-by: Jonathan Maple <[email protected]>

# Conflicts:
#	fs/xfs/libxfs/xfs_bmap.c
#	fs/xfs/scrub/quota_repair.c
#	fs/xfs/scrub/rtbitmap_repair.c
#	fs/xfs/xfs_iomap.c

jira LE-4321
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Matthias Stocker <[email protected]>
commit ffbe335

When vmxnet3_rq_create() fails to allocate memory for rq->data_ring.base,
the subsequent call to vmxnet3_rq_destroy_all_rxdataring does not reset
rq->data_ring.desc_size for the data ring that failed, which presumably
causes the hypervisor to reference it on packet reception.

To fix this bug, rq->data_ring.desc_size needs to be set to 0 to tell
the hypervisor to disable this feature.

[   95.436876] kernel BUG at net/core/skbuff.c:207!
[   95.439074] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[   95.440411] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 6.9.3-dirty #1
[   95.441558] Hardware name: VMware, Inc. VMware Virtual
Platform/440BX Desktop Reference Platform, BIOS 6.00 12/12/2018
[   95.443481] RIP: 0010:skb_panic+0x4d/0x4f
[   95.444404] Code: 4f 70 50 8b 87 c0 00 00 00 50 8b 87 bc 00 00 00 50
ff b7 d0 00 00 00 4c 8b 8f c8 00 00 00 48 c7 c7 68 e8 be 9f e8 63 58 f9
ff <0f> 0b 48 8b 14 24 48 c7 c1 d0 73 65 9f e8 a1 ff ff ff 48 8b 14 24
[   95.447684] RSP: 0018:ffffa13340274dd0 EFLAGS: 00010246
[   95.448762] RAX: 0000000000000089 RBX: ffff8fbbc72b02d0 RCX: 000000000000083f
[   95.450148] RDX: 0000000000000000 RSI: 00000000000000f6 RDI: 000000000000083f
[   95.451520] RBP: 000000000000002d R08: 0000000000000000 R09: ffffa13340274c60
[   95.452886] R10: ffffffffa04ed468 R11: 0000000000000002 R12: 0000000000000000
[   95.454293] R13: ffff8fbbdab3c2d0 R14: ffff8fbbdbd829e0 R15: ffff8fbbdbd809e0
[   95.455682] FS:  0000000000000000(0000) GS:ffff8fbeefd80000(0000) knlGS:0000000000000000
[   95.457178] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   95.458340] CR2: 00007fd0d1f650c8 CR3: 0000000115f28000 CR4: 00000000000406f0
[   95.459791] Call Trace:
[   95.460515]  <IRQ>
[   95.461180]  ? __die_body.cold+0x19/0x27
[   95.462150]  ? die+0x2e/0x50
[   95.462976]  ? do_trap+0xca/0x110
[   95.463973]  ? do_error_trap+0x6a/0x90
[   95.464966]  ? skb_panic+0x4d/0x4f
[   95.465901]  ? exc_invalid_op+0x50/0x70
[   95.466849]  ? skb_panic+0x4d/0x4f
[   95.467718]  ? asm_exc_invalid_op+0x1a/0x20
[   95.468758]  ? skb_panic+0x4d/0x4f
[   95.469655]  skb_put.cold+0x10/0x10
[   95.470573]  vmxnet3_rq_rx_complete+0x862/0x11e0 [vmxnet3]
[   95.471853]  vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3]
[   95.473185]  __napi_poll+0x2b/0x160
[   95.474145]  net_rx_action+0x2c6/0x3b0
[   95.475115]  handle_softirqs+0xe7/0x2a0
[   95.476122]  __irq_exit_rcu+0x97/0xb0
[   95.477109]  common_interrupt+0x85/0xa0
[   95.478102]  </IRQ>
[   95.478846]  <TASK>
[   95.479603]  asm_common_interrupt+0x26/0x40
[   95.480657] RIP: 0010:pv_native_safe_halt+0xf/0x20
[   95.481801] Code: 22 d7 e9 54 87 01 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d 93 ba 3b 00 fb f4 <e9> 2c 87 01 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90
[   95.485563] RSP: 0018:ffffa133400ffe58 EFLAGS: 00000246
[   95.486882] RAX: 0000000000004000 RBX: ffff8fbbc1d14064 RCX: 0000000000000000
[   95.488477] RDX: ffff8fbeefd80000 RSI: ffff8fbbc1d14000 RDI: 0000000000000001
[   95.490067] RBP: ffff8fbbc1d14064 R08: ffffffffa0652260 R09: 00000000000010d3
[   95.491683] R10: 0000000000000018 R11: ffff8fbeefdb4764 R12: ffffffffa0652260
[   95.493389] R13: ffffffffa06522e0 R14: 0000000000000001 R15: 0000000000000000
[   95.495035]  acpi_safe_halt+0x14/0x20
[   95.496127]  acpi_idle_do_entry+0x2f/0x50
[   95.497221]  acpi_idle_enter+0x7f/0xd0
[   95.498272]  cpuidle_enter_state+0x81/0x420
[   95.499375]  cpuidle_enter+0x2d/0x40
[   95.500400]  do_idle+0x1e5/0x240
[   95.501385]  cpu_startup_entry+0x29/0x30
[   95.502422]  start_secondary+0x11c/0x140
[   95.503454]  common_startup_64+0x13e/0x141
[   95.504466]  </TASK>
[   95.505197] Modules linked in: nft_fib_inet nft_fib_ipv4
nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6
nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6
nf_defrag_ipv4 rfkill ip_set nf_tables vsock_loopback
vmw_vsock_virtio_transport_common qrtr vmw_vsock_vmci_transport vsock
sunrpc binfmt_misc pktcdvd vmw_balloon pcspkr vmw_vmci i2c_piix4 joydev
loop dm_multipath nfnetlink zram crct10dif_pclmul crc32_pclmul vmwgfx
crc32c_intel polyval_clmulni polyval_generic ghash_clmulni_intel
sha512_ssse3 sha256_ssse3 vmxnet3 sha1_ssse3 drm_ttm_helper vmw_pvscsi
ttm ata_generic pata_acpi serio_raw scsi_dh_rdac scsi_dh_emc
scsi_dh_alua ip6_tables ip_tables fuse
[   95.516536] ---[ end trace 0000000000000000 ]---

Fixes: 6f48333 ("net: vmxnet3: Fix NULL pointer dereference in vmxnet3_rq_rx_complete()")
	Signed-off-by: Matthias Stocker <[email protected]>
	Reviewed-by: Subbaraya Sundeep <[email protected]>
	Reviewed-by: Ronak Doshi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit ffbe335)
	Signed-off-by: Jonathan Maple <[email protected]>

…ck_t

jira LE-4321
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
Rebuild_CHGLOG: - tracing: Disable interrupt or preemption before acquiring arch_spinlock_t (partial) (Luis Claudio R. Goncalves) [RHEL-95713]
Rebuild_FUZZ: 93.59%
commit-author Waiman Long <[email protected]>
commit c0a581d
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-4.18.0-553.76.1.el8_10/c0a581d7.failed

It was found that some tracing functions in kernel/trace/trace.c acquire
an arch_spinlock_t with preemption and irqs enabled. An example is the
tracing_saved_cmdlines_size_read() function which intermittently causes
a "BUG: using smp_processor_id() in preemptible" warning when the LTP
read_all_proc test is run.

That can be problematic in case preemption happens after acquiring the
lock. Add the necessary preemption or interrupt disabling code in the
appropriate places before acquiring an arch_spinlock_t.

The convention here is to disable preemption for trace_cmdline_lock and
interupt for max_lock.

Link: https://lkml.kernel.org/r/[email protected]

	Cc: Peter Zijlstra <[email protected]>
	Cc: Ingo Molnar <[email protected]>
	Cc: Will Deacon <[email protected]>
	Cc: Boqun Feng <[email protected]>
	Cc: [email protected]
Fixes: a35873a ("tracing: Add conditional snapshot")
Fixes: 939c7a4 ("tracing: Introduce saved_cmdlines_size file")
	Suggested-by: Steven Rostedt <[email protected]>
	Signed-off-by: Waiman Long <[email protected]>
	Signed-off-by: Steven Rostedt (Google) <[email protected]>
(cherry picked from commit c0a581d)
	Signed-off-by: Jonathan Maple <[email protected]>

# Conflicts:
#	kernel/trace/trace.c

jira LE-4321
cve CVE-2025-38449
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Thomas Zimmermann <[email protected]>
commit 5307dce

A GEM handle can be released while the GEM buffer object is attached
to a DRM framebuffer. This leads to the release of the dma-buf backing
the buffer object, if any. [1] Trying to use the framebuffer in further
mode-setting operations leads to a segmentation fault. Most easily
happens with driver that use shadow planes for vmap-ing the dma-buf
during a page flip. An example is shown below.

[  156.791968] ------------[ cut here ]------------
[  156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430
[...]
[  156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430
[  157.043420] Call Trace:
[  157.045898]  <TASK>
[  157.048030]  ? show_trace_log_lvl+0x1af/0x2c0
[  157.052436]  ? show_trace_log_lvl+0x1af/0x2c0
[  157.056836]  ? show_trace_log_lvl+0x1af/0x2c0
[  157.061253]  ? drm_gem_shmem_vmap+0x74/0x710
[  157.065567]  ? dma_buf_vmap+0x224/0x430
[  157.069446]  ? __warn.cold+0x58/0xe4
[  157.073061]  ? dma_buf_vmap+0x224/0x430
[  157.077111]  ? report_bug+0x1dd/0x390
[  157.080842]  ? handle_bug+0x5e/0xa0
[  157.084389]  ? exc_invalid_op+0x14/0x50
[  157.088291]  ? asm_exc_invalid_op+0x16/0x20
[  157.092548]  ? dma_buf_vmap+0x224/0x430
[  157.096663]  ? dma_resv_get_singleton+0x6d/0x230
[  157.101341]  ? __pfx_dma_buf_vmap+0x10/0x10
[  157.105588]  ? __pfx_dma_resv_get_singleton+0x10/0x10
[  157.110697]  drm_gem_shmem_vmap+0x74/0x710
[  157.114866]  drm_gem_vmap+0xa9/0x1b0
[  157.118763]  drm_gem_vmap_unlocked+0x46/0xa0
[  157.123086]  drm_gem_fb_vmap+0xab/0x300
[  157.126979]  drm_atomic_helper_prepare_planes.part.0+0x487/0xb10
[  157.133032]  ? lockdep_init_map_type+0x19d/0x880
[  157.137701]  drm_atomic_helper_commit+0x13d/0x2e0
[  157.142671]  ? drm_atomic_nonblocking_commit+0xa0/0x180
[  157.147988]  drm_mode_atomic_ioctl+0x766/0xe40
[...]
[  157.346424] ---[ end trace 0000000000000000 ]---

Acquiring GEM handles for the framebuffer's GEM buffer objects prevents
this from happening. The framebuffer's cleanup later puts the handle
references.

Commit 1a148af ("drm/gem-shmem: Use dma_buf from GEM object
instance") triggers the segmentation fault easily by using the dma-buf
field more widely. The underlying issue with reference counting has
been present before.

v2:
- acquire the handle instead of the BO (Christian)
- fix comment style (Christian)
- drop the Fixes tag (Christian)
- rename err_ gotos
- add missing Link tag

	Suggested-by: Christian König <[email protected]>
	Signed-off-by: Thomas Zimmermann <[email protected]>
Link: https://elixir.bootlin.com/linux/v6.15/source/drivers/gpu/drm/drm_gem.c#L241 # [1]
	Cc: Thomas Zimmermann <[email protected]>
	Cc: Anusha Srivatsa <[email protected]>
	Cc: Christian König <[email protected]>
	Cc: Maarten Lankhorst <[email protected]>
	Cc: Maxime Ripard <[email protected]>
	Cc: Sumit Semwal <[email protected]>
	Cc: "Christian König" <[email protected]>
	Cc: [email protected]
	Cc: [email protected]
	Cc: [email protected]
	Cc: <[email protected]>
	Reviewed-by: Christian König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
(cherry picked from commit 5307dce)
	Signed-off-by: Jonathan Maple <[email protected]>

jira LE-4321
cve CVE-2025-38449
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Thomas Zimmermann <[email protected]>
commit f6bfc9a
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-4.18.0-553.76.1.el8_10/f6bfc9af.failed

Acquire GEM handles in drm_framebuffer_init() and release them in
the corresponding drm_framebuffer_cleanup(). Ties the handle's
lifetime to the framebuffer. Not all GEM buffer objects have GEM
handles. If not set, no refcounting takes place. This is the case
for some fbdev emulation. This is not a problem as these GEM objects
do not use dma-bufs and drivers will not release them while fbdev
emulation is running. Framebuffer flags keep a bit per color plane
of which the framebuffer holds a GEM handle reference.

As all drivers use drm_framebuffer_init(), they will now all hold
dma-buf references as fixed in commit 5307dce ("drm/gem: Acquire
references on GEM handles for framebuffers").

In the GEM framebuffer helpers, restore the original ref counting
on buffer objects. As the helpers for handle refcounting are now
no longer called from outside the DRM core, unexport the symbols.

v3:
- don't mix internal flags with mode flags (Christian)
v2:
- track framebuffer handle refs by flag
- drop gma500 cleanup (Christian)

	Signed-off-by: Thomas Zimmermann <[email protected]>
Fixes: 5307dce ("drm/gem: Acquire references on GEM handles for framebuffers")
	Reported-by: Bert Karwatzki <[email protected]>
Closes: https://lore.kernel.org/dri-devel/[email protected]/
	Tested-by: Bert Karwatzki <[email protected]>
	Tested-by: Mario Limonciello <[email protected]>
	Tested-by: Borislav Petkov (AMD) <[email protected]>
	Cc: Thomas Zimmermann <[email protected]>
	Cc: Anusha Srivatsa <[email protected]>
	Cc: Christian König <[email protected]>
	Cc: Maarten Lankhorst <[email protected]>
	Cc: Maxime Ripard <[email protected]>
	Cc: Sumit Semwal <[email protected]>
	Cc: "Christian König" <[email protected]>
	Cc: [email protected]
	Cc: [email protected]
	Cc: [email protected]
	Cc: <[email protected]>
	Reviewed-by: Christian König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
(cherry picked from commit f6bfc9a)
	Signed-off-by: Jonathan Maple <[email protected]>

# Conflicts:
#	include/drm/drm_framebuffer.h

jira LE-4321
cve CVE-2025-38392
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Ahmed Zaki <[email protected]>
commit b2beb5b

With VIRTCHNL2_CAP_MACFILTER enabled, the following warning is generated
on module load:

[  324.701677] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578
[  324.701684] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1582, name: NetworkManager
[  324.701689] preempt_count: 201, expected: 0
[  324.701693] RCU nest depth: 0, expected: 0
[  324.701697] 2 locks held by NetworkManager/1582:
[  324.701702]  #0: ffffffff9f7be770 (rtnl_mutex){....}-{3:3}, at: rtnl_newlink+0x791/0x21e0
[  324.701730]  #1: ff1100216c380368 (_xmit_ETHER){....}-{2:2}, at: __dev_open+0x3f0/0x870
[  324.701749] Preemption disabled at:
[  324.701752] [<ffffffff9cd23b9d>] __dev_open+0x3dd/0x870
[  324.701765] CPU: 30 UID: 0 PID: 1582 Comm: NetworkManager Not tainted 6.15.0-rc5+ #2 PREEMPT(voluntary)
[  324.701771] Hardware name: Intel Corporation M50FCP2SBSTD/M50FCP2SBSTD, BIOS SE5C741.86B.01.01.0001.2211140926 11/14/2022
[  324.701774] Call Trace:
[  324.701777]  <TASK>
[  324.701779]  dump_stack_lvl+0x5d/0x80
[  324.701788]  ? __dev_open+0x3dd/0x870
[  324.701793]  __might_resched.cold+0x1ef/0x23d
<..>
[  324.701818]  __mutex_lock+0x113/0x1b80
<..>
[  324.701917]  idpf_ctlq_clean_sq+0xad/0x4b0 [idpf]
[  324.701935]  ? kasan_save_track+0x14/0x30
[  324.701941]  idpf_mb_clean+0x143/0x380 [idpf]
<..>
[  324.701991]  idpf_send_mb_msg+0x111/0x720 [idpf]
[  324.702009]  idpf_vc_xn_exec+0x4cc/0x990 [idpf]
[  324.702021]  ? rcu_is_watching+0x12/0xc0
[  324.702035]  idpf_add_del_mac_filters+0x3ed/0xb50 [idpf]
<..>
[  324.702122]  __hw_addr_sync_dev+0x1cf/0x300
[  324.702126]  ? find_held_lock+0x32/0x90
[  324.702134]  idpf_set_rx_mode+0x317/0x390 [idpf]
[  324.702152]  __dev_open+0x3f8/0x870
[  324.702159]  ? __pfx___dev_open+0x10/0x10
[  324.702174]  __dev_change_flags+0x443/0x650
<..>
[  324.702208]  netif_change_flags+0x80/0x160
[  324.702218]  do_setlink.isra.0+0x16a0/0x3960
<..>
[  324.702349]  rtnl_newlink+0x12fd/0x21e0

The sequence is as follows:
	rtnl_newlink()->
	__dev_change_flags()->
	__dev_open()->
	dev_set_rx_mode() - >  # disables BH and grabs "dev->addr_list_lock"
	idpf_set_rx_mode() ->  # proceed only if VIRTCHNL2_CAP_MACFILTER is ON
	__dev_uc_sync() ->
	idpf_add_mac_filter ->
	idpf_add_del_mac_filters ->
	idpf_send_mb_msg() ->
	idpf_mb_clean() ->
	idpf_ctlq_clean_sq()   # mutex_lock(cq_lock)

Fix by converting cq_lock to a spinlock. All operations under the new
lock are safe except freeing the DMA memory, which may use vunmap(). Fix
by requesting a contiguous physical memory for the DMA mapping.

Fixes: a251eee ("idpf: add SRIOV support and other ndo_ops")
	Reviewed-by: Aleksandr Loktionov <[email protected]>
	Signed-off-by: Ahmed Zaki <[email protected]>
	Reviewed-by: Simon Horman <[email protected]>
	Tested-by: Samuel Salin <[email protected]>
	Signed-off-by: Tony Nguyen <[email protected]>
(cherry picked from commit b2beb5b)
	Signed-off-by: Jonathan Maple <[email protected]>

jira LE-4321
cve CVE-2025-38107
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Eric Dumazet <[email protected]>
commit d92adac

Gerrard Tai reported a race condition in ETS, whenever SFQ perturb timer
fires at the wrong time.

The race is as follows:

CPU 0                                 CPU 1
[1]: lock root
[2]: qdisc_tree_flush_backlog()
[3]: unlock root
 |
 |                                    [5]: lock root
 |                                    [6]: rehash
 |                                    [7]: qdisc_tree_reduce_backlog()
 |
[4]: qdisc_put()

This can be abused to underflow a parent's qlen.

Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()
should fix the race, because all packets will be purged from the qdisc
before releasing the lock.

Fixes: b05972f ("net: sched: tbf: don't call qdisc_put() while holding tree lock")
	Reported-by: Gerrard Tai <[email protected]>
	Suggested-by: Gerrard Tai <[email protected]>
	Signed-off-by: Eric Dumazet <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit d92adac)
	Signed-off-by: Jonathan Maple <[email protected]>

jira LE-4321
cve CVE-2025-38350
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Eric Dumazet <[email protected]>
commit c5f1dde

Instead of relying on RTNL, ets_dump() can use READ_ONCE()
annotations, paired with WRITE_ONCE() ones in ets_change().

	Signed-off-by: Eric Dumazet <[email protected]>
	Reviewed-by: Simon Horman <[email protected]>
	Signed-off-by: David S. Miller <[email protected]>
(cherry picked from commit c5f1dde)
	Signed-off-by: Jonathan Maple <[email protected]>

jira LE-4321
cve CVE-2025-38350
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Davide Caratti <[email protected]>
commit 87c6efc

Shuang reported sch_ets test-case [1] crashing in ets_class_qlen_notify()
after recent changes from Lion [2]. The problem is: in ets_qdisc_change()
we purge unused DWRR queues; the value of 'q->nbands' is the new one, and
the cleanup should be done with the old one. The problem is here since my
first attempts to fix ets_qdisc_change(), but it surfaced again after the
recent qdisc len accounting fixes. Fix it purging idle DWRR queues before
assigning a new value of 'q->nbands', so that all purge operations find a
consistent configuration:

 - old 'q->nbands' because it's needed by ets_class_find()
 - old 'q->nstrict' because it's needed by ets_class_is_strict()

 BUG: kernel NULL pointer dereference, address: 0000000000000000
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: Oops: 0000 [#1] SMP NOPTI
 CPU: 62 UID: 0 PID: 39457 Comm: tc Kdump: loaded Not tainted 6.12.0-116.el10.x86_64 #1 PREEMPT(voluntary)
 Hardware name: Dell Inc. PowerEdge R640/06DKY5, BIOS 2.12.2 07/09/2021
 RIP: 0010:__list_del_entry_valid_or_report+0x4/0x80
 Code: ff 4c 39 c7 0f 84 39 19 8e ff b8 01 00 00 00 c3 cc cc cc cc 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <48> 8b 17 48 8b 4f 08 48 85 d2 0f 84 56 19 8e ff 48 85 c9 0f 84 ab
 RSP: 0018:ffffba186009f400 EFLAGS: 00010202
 RAX: 00000000000000d6 RBX: 0000000000000000 RCX: 0000000000000004
 RDX: ffff9f0fa29b69c0 RSI: 0000000000000000 RDI: 0000000000000000
 RBP: ffffffffc12c2400 R08: 0000000000000008 R09: 0000000000000004
 R10: ffffffffffffffff R11: 0000000000000004 R12: 0000000000000000
 R13: ffff9f0f8cfe0000 R14: 0000000000100005 R15: 0000000000000000
 FS:  00007f2154f37480(0000) GS:ffff9f269c1c0000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000000 CR3: 00000001530be001 CR4: 00000000007726f0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 PKRU: 55555554
 Call Trace:
  <TASK>
  ets_class_qlen_notify+0x65/0x90 [sch_ets]
  qdisc_tree_reduce_backlog+0x74/0x110
  ets_qdisc_change+0x630/0xa40 [sch_ets]
  __tc_modify_qdisc.constprop.0+0x216/0x7f0
  tc_modify_qdisc+0x7c/0x120
  rtnetlink_rcv_msg+0x145/0x3f0
  netlink_rcv_skb+0x53/0x100
  netlink_unicast+0x245/0x390
  netlink_sendmsg+0x21b/0x470
  ____sys_sendmsg+0x39d/0x3d0
  ___sys_sendmsg+0x9a/0xe0
  __sys_sendmsg+0x7a/0xd0
  do_syscall_64+0x7d/0x160
  entry_SYSCALL_64_after_hwframe+0x76/0x7e
 RIP: 0033:0x7f2155114084
 Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d 25 f0 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89
 RSP: 002b:00007fff1fd7a988 EFLAGS: 00000202 ORIG_RAX: 000000000000002e
 RAX: ffffffffffffffda RBX: 0000560ec063e5e0 RCX: 00007f2155114084
 RDX: 0000000000000000 RSI: 00007fff1fd7a9f0 RDI: 0000000000000003
 RBP: 00007fff1fd7aa60 R08: 0000000000000010 R09: 000000000000003f
 R10: 0000560ee9b3a010 R11: 0000000000000202 R12: 00007fff1fd7aae0
 R13: 000000006891ccde R14: 0000560ec063e5e0 R15: 00007fff1fd7aad0
  </TASK>

 [1] https://lore.kernel.org/netdev/e08c7f4a6882f260011909a868311c6e9b54f3e4.1639153474.git.dcaratti@redhat.com/
 [2] https://lore.kernel.org/netdev/[email protected]/

	Cc: [email protected]
Fixes: 103406b ("net/sched: Always pass notifications when child class becomes empty")
Fixes: c062f2a ("net/sched: sch_ets: don't remove idle classes from the round-robin list")
Fixes: dcc68b4 ("net: sch_ets: Add a new Qdisc")
	Reported-by: Li Shuang <[email protected]>
Closes: https://issues.redhat.com/browse/RHEL-108026
	Reviewed-by: Petr Machata <[email protected]>
Co-developed-by: Ivan Vecera <[email protected]>
	Signed-off-by: Ivan Vecera <[email protected]>
	Signed-off-by: Davide Caratti <[email protected]>
Link: https://patch.msgid.link/7928ff6d17db47a2ae7cc205c44777b1f1950545.1755016081.git.dcaratti@redhat.com
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit 87c6efc)
	Signed-off-by: Jonathan Maple <[email protected]>

…ync is used"

jira LE-4321
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Igor Pylypiv <[email protected]>
commit 67d6212

This reverts commit 774a122.

We need to finish all async code before the module init sequence is
done.  In the reverted commit the PF_USED_ASYNC flag was added to mark a
thread that called async_schedule().  Then the PF_USED_ASYNC flag was
used to determine whether or not async_synchronize_full() needs to be
invoked.  This works when modprobe thread is calling async_schedule(),
but it does not work if module dispatches init code to a worker thread
which then calls async_schedule().

For example, PCI driver probing is invoked from a worker thread based on
a node where device is attached:

	if (cpu < nr_cpu_ids)
		error = work_on_cpu(cpu, local_pci_probe, &ddi);
	else
		error = local_pci_probe(&ddi);

We end up in a situation where a worker thread gets the PF_USED_ASYNC
flag set instead of the modprobe thread.  As a result,
async_synchronize_full() is not invoked and modprobe completes without
waiting for the async code to finish.

The issue was discovered while loading the pm80xx driver:
(scsi_mod.scan=async)

modprobe pm80xx                      worker
...
  do_init_module()
  ...
    pci_call_probe()
      work_on_cpu(local_pci_probe)
                                     local_pci_probe()
                                       pm8001_pci_probe()
                                         scsi_scan_host()
                                           async_schedule()
                                           worker->flags |= PF_USED_ASYNC;
                                     ...
      < return from worker >
  ...
  if (current->flags & PF_USED_ASYNC) <--- false
  	async_synchronize_full();

Commit 21c3c5d ("block: don't request module during elevator init")
fixed the deadlock issue which the reverted commit 774a122
("module, async: async_synchronize_full() on module init iff async is
used") tried to fix.

Since commit 0fdff3e ("async, kmod: warn on synchronous
request_module() from async workers") synchronous module loading from
async is not allowed.

Given that the original deadlock issue is fixed and it is no longer
allowed to call synchronous request_module() from async we can remove
PF_USED_ASYNC flag to make module init consistently invoke
async_synchronize_full() unless async module probe is requested.

	Signed-off-by: Igor Pylypiv <[email protected]>
	Reviewed-by: Changyuan Lyu <[email protected]>
	Reviewed-by: Luis Chamberlain <[email protected]>
	Acked-by: Tejun Heo <[email protected]>
	Signed-off-by: Linus Torvalds <[email protected]>
(cherry picked from commit 67d6212)
	Signed-off-by: Jonathan Maple <[email protected]>

jira LE-4321
cve CVE-2025-38461
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Michal Luczaj <[email protected]>
commit 687aa0c

Transport assignment may race with module unload. Protect new_transport
from becoming a stale pointer.

This also takes care of an insecure call in vsock_use_local_transport();
add a lockdep assert.

BUG: unable to handle page fault for address: fffffbfff8056000
Oops: Oops: 0000 [#1] SMP KASAN
RIP: 0010:vsock_assign_transport+0x366/0x600
Call Trace:
 vsock_connect+0x59c/0xc40
 __sys_connect+0xe8/0x100
 __x64_sys_connect+0x6e/0xc0
 do_syscall_64+0x92/0x1c0
 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Fixes: c0cfa2d ("vsock: add multi-transports support")
	Reviewed-by: Stefano Garzarella <[email protected]>
	Signed-off-by: Michal Luczaj <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit 687aa0c)
	Signed-off-by: Jonathan Maple <[email protected]>

jira LE-4321
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Wengang Wang <[email protected]>
commit 58f8807
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-4.18.0-553.76.1.el8_10/58f88071.failed

A user with a completely full filesystem experienced an unexpected
shutdown when the filesystem tried to write the superblock during
runtime.
kernel shows the following dmesg:

[    8.176281] XFS (dm-4): Metadata corruption detected at xfs_sb_write_verify+0x60/0x120 [xfs], xfs_sb block 0x0
[    8.177417] XFS (dm-4): Unmount and run xfs_repair
[    8.178016] XFS (dm-4): First 128 bytes of corrupted metadata buffer:
[    8.178703] 00000000: 58 46 53 42 00 00 10 00 00 00 00 00 01 90 00 00  XFSB............
[    8.179487] 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[    8.180312] 00000020: cf 12 dc 89 ca 26 45 29 92 e6 e3 8d 3b b8 a2 c3  .....&E)....;...
[    8.181150] 00000030: 00 00 00 00 01 00 00 06 00 00 00 00 00 00 00 80  ................
[    8.182003] 00000040: 00 00 00 00 00 00 00 81 00 00 00 00 00 00 00 82  ................
[    8.182004] 00000050: 00 00 00 01 00 64 00 00 00 00 00 04 00 00 00 00  .....d..........
[    8.182004] 00000060: 00 00 64 00 b4 a5 02 00 02 00 00 08 00 00 00 00  ..d.............
[    8.182005] 00000070: 00 00 00 00 00 00 00 00 0c 09 09 03 17 00 00 19  ................
[    8.182008] XFS (dm-4): Corruption of in-memory data detected.  Shutting down filesystem
[    8.182010] XFS (dm-4): Please unmount the filesystem and rectify the problem(s)

When xfs_log_sb writes super block to disk, b_fdblocks is fetched from
m_fdblocks without any lock. As m_fdblocks can experience a positive ->
negative -> positive changing when the FS reaches fullness (see
xfs_mod_fdblocks). So there is a chance that sb_fdblocks is negative, and
because sb_fdblocks is type of unsigned long long, it reads super big.
And sb_fdblocks being bigger than sb_dblocks is a problem during log
recovery, xfs_validate_sb_write() complains.

Fix:
As sb_fdblocks will be re-calculated during mount when lazysbcount is
enabled, We just need to make xfs_validate_sb_write() happy -- make sure
sb_fdblocks is not nenative. This patch also takes care of other percpu
counters in xfs_log_sb.

	Signed-off-by: Wengang Wang <[email protected]>
	Reviewed-by: Darrick J. Wong <[email protected]>
	Signed-off-by: Chandan Babu R <[email protected]>
(cherry picked from commit 58f8807)
	Signed-off-by: Jonathan Maple <[email protected]>

# Conflicts:
#	fs/xfs/libxfs/xfs_sb.c

jira LE-4321
cve CVE-2025-38498
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Al Viro <[email protected]>
commit 12f147d

Ensure that propagation settings can only be changed for mounts located
in the caller's mount namespace. This change aligns permission checking
with the rest of mount(2).

	Reviewed-by: Christian Brauner <[email protected]>
Fixes: 07b2088 ("beginning of the shared-subtree proper")
	Reported-by: "Orlando, Noah" <[email protected]>
	Signed-off-by: Al Viro <[email protected]>
(cherry picked from commit 12f147d)
	Signed-off-by: Jonathan Maple <[email protected]>

jira LE-4321
cve CVE-2025-38498
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Al Viro <[email protected]>
commit cffd044
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-4.18.0-553.76.1.el8_10/cffd0441.failed

do_change_type() and do_set_group() are operating on different
aspects of the same thing - propagation graph.  The latter
asks for mounts involved to be mounted in namespace(s) the caller
has CAP_SYS_ADMIN for.  The former is a mess - originally it
didn't even check that mount *is* mounted.  That got fixed,
but the resulting check turns out to be too strict for userland -
in effect, we check that mount is in our namespace, having already
checked that we have CAP_SYS_ADMIN there.

What we really need (in both cases) is
	* only touch mounts that are mounted.  That's a must-have
constraint - data corruption happens if it get violated.
	* don't allow to mess with a namespace unless you already
have enough permissions to do so (i.e. CAP_SYS_ADMIN in its userns).

That's an equivalent of what do_set_group() does; let's extract that
into a helper (may_change_propagation()) and use it in both
do_set_group() and do_change_type().

Fixes: 12f147d "do_change_type(): refuse to operate on unmounted/not ours mounts"
	Acked-by: Andrei Vagin <[email protected]>
	Reviewed-by: Pavel Tikhomirov <[email protected]>
	Tested-by: Pavel Tikhomirov <[email protected]>
	Reviewed-by: Christian Brauner <[email protected]>
	Signed-off-by: Al Viro <[email protected]>
(cherry picked from commit cffd044)
	Signed-off-by: Jonathan Maple <[email protected]>

# Conflicts:
#	fs/namespace.c

jira LE-4321
cve CVE-2025-38556
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author ZhangPeng <[email protected]>
commit ec61b41

Syzbot reported shift-out-of-bounds in hid_report_raw_event.

microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) >
32! (swapper/0)
======================================================================
UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20
shift exponent 127 is too large for 32-bit type 'int'
CPU: 0 PID: 0 Comm: swapper/0 Not tainted
6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS
Google 10/26/2022
Call Trace:
 <IRQ>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106
 ubsan_epilogue lib/ubsan.c:151 [inline]
 __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322
 snto32 drivers/hid/hid-core.c:1323 [inline]
 hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline]
 hid_process_report drivers/hid/hid-core.c:1665 [inline]
 hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998
 hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066
 hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284
 __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671
 dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988
 call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474
 expire_timers kernel/time/timer.c:1519 [inline]
 __run_timers+0x76a/0x980 kernel/time/timer.c:1790
 run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803
 __do_softirq+0x277/0x75b kernel/softirq.c:571
 __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650
 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662
 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107
======================================================================

If the size of the integer (unsigned n) is bigger than 32 in snto32(),
shift exponent will be too large for 32-bit type 'int', resulting in a
shift-out-of-bounds bug.
Fix this by adding a check on the size of the integer (unsigned n) in
snto32(). To add support for n greater than 32 bits, set n to 32, if n
is greater than 32.

	Reported-by: [email protected]
Fixes: dde5845 ("[PATCH] Generic HID layer - code split")
	Signed-off-by: ZhangPeng <[email protected]>
	Signed-off-by: Jiri Kosina <[email protected]>
(cherry picked from commit ec61b41)
	Signed-off-by: Jonathan Maple <[email protected]>

jira LE-4321
cve CVE-2025-38556
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Dmitry Torokhov <[email protected]>
commit ae9b956

snto32() does exactly what sign_extend32() does, but handles
potentially malformed data coming from the device. Keep the checks,
but then call sign_extend32() to perform the actual conversion.

	Signed-off-by: Dmitry Torokhov <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Benjamin Tissoires <[email protected]>
(cherry picked from commit ae9b956)
	Signed-off-by: Jonathan Maple <[email protected]>

jira LE-4321
cve CVE-2025-38556
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Dmitry Torokhov <[email protected]>
commit c653ffc

The only user of hid_snto32() is Logitech HID++ driver, which always
calls hid_snto32() with valid size (constant, either 12 or 8) and
therefore can simply use sign_extend32().

Make the switch and remove hid_snto32(). Move snto32() and s32ton() to
avoid introducing forward declaration.

	Signed-off-by: Dmitry Torokhov <[email protected]>
Link: https://patch.msgid.link/[email protected]
[bentiss: fix checkpatch warning]
	Signed-off-by: Benjamin Tissoires <[email protected]>
(cherry picked from commit c653ffc)
	Signed-off-by: Jonathan Maple <[email protected]>

jira LE-4321
cve CVE-2025-38556
Rebuild_History Non-Buildable kernel-4.18.0-553.76.1.el8_10
commit-author Alan Stern <[email protected]>
commit a6b87bf

Testing by the syzbot fuzzer showed that the HID core gets a
shift-out-of-bounds exception when it tries to convert a 32-bit
quantity to a 0-bit quantity.  Ideally this should never occur, but
there are buggy devices and some might have a report field with size
set to zero; we shouldn't reject the report or the device just because
of that.

Instead, harden the s32ton() routine so that it returns a reasonable
result instead of crashing when it is called with the number of bits
set to 0 -- the same as what snto32() does.

	Signed-off-by: Alan Stern <[email protected]>
	Reported-by: [email protected]
Closes: https://lore.kernel.org/linux-usb/[email protected]/
	Tested-by: [email protected]
Fixes: dde5845 ("[PATCH] Generic HID layer - code split")
	Cc: [email protected]
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Benjamin Tissoires <[email protected]>
(cherry picked from commit a6b87bf)
	Signed-off-by: Jonathan Maple <[email protected]>

Rebuild_History BUILDABLE
Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50%
Number of commits in upstream range v4.18~1..kernel-mainline: 567757
Number of commits in rpm: 36
Number of commits matched with upstream: 29 (80.56%)
Number of commits in upstream but not in rpm: 567729
Number of commits NOT found in upstream: 7 (19.44%)

Rebuilding Kernel on Branch rocky8_10_rebuild_kernel-4.18.0-553.76.1.el8_10 for kernel-4.18.0-553.76.1.el8_10
Clean Cherry Picks: 17 (58.62%)
Empty Cherry Picks: 5 (17.24%)
_______________________________

Full Details Located here:
ciq/ciq_backports/kernel-4.18.0-553.76.1.el8_10/rebuild.details.txt

Includes:
* git commit header above
* Empty Commits with upstream SHA
* RPM ChangeLog Entries that could not be matched

Individual Empty Commit failures contained in the same containing directory.
The git message for empty commits will have the path for the failed commit.
File names are the first 8 characters of the upstream SHA

jira LE-4321
cve CVE-2025-22026
Rebuild_History Non-Buildable kernel-4.18.0-553.77.1.el8_10
commit-author Jeff Layton <[email protected]>
commit 930b64c
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-4.18.0-553.77.1.el8_10/930b64ca.failed

Currently, nfsd_proc_stat_init() ignores the return value of
svc_proc_register(). If the procfile creation fails, then the kernel
will WARN when it tries to remove the entry later.

Fix nfsd_proc_stat_init() to return the same type of pointer as
svc_proc_register(), and fix up nfsd_net_init() to check that and fail
the nfsd_net construction if it occurs.

svc_proc_register() can fail if the dentry can't be allocated, or if an
identical dentry already exists. The second case is pretty unlikely in
the nfsd_net construction codepath, so if this happens, return -ENOMEM.

	Reported-by: [email protected]
Closes: https://lore.kernel.org/linux-nfs/[email protected]/
	Cc: [email protected] # v6.9
	Signed-off-by: Jeff Layton <[email protected]>
	Signed-off-by: Chuck Lever <[email protected]>
(cherry picked from commit 930b64c)
	Signed-off-by: Jonathan Maple <[email protected]>

# Conflicts:
#	fs/nfsd/nfsctl.c
#	fs/nfsd/stats.c
#	fs/nfsd/stats.h

jira LE-4321
cve CVE-2022-50087
Rebuild_History Non-Buildable kernel-4.18.0-553.77.1.el8_10
commit-author Sudeep Holla <[email protected]>
commit 689640e
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-4.18.0-553.77.1.el8_10/689640ef.failed

When scpi probe fails, at any point, we need to ensure that the scpi_info
is not set and will remain NULL until the probe succeeds. If it is not
taken care, then it could result use-after-free as the value is exported
via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc()
but freed when the probe fails.

Link: https://lore.kernel.org/r/[email protected]
	Cc: [email protected] # 4.19+
	Reported-by: huhai <[email protected]>
	Reviewed-by: Jackie Liu <[email protected]>
	Signed-off-by: Sudeep Holla <[email protected]>
(cherry picked from commit 689640e)
	Signed-off-by: Jonathan Maple <[email protected]>

# Conflicts:
#	drivers/firmware/arm_scpi.c

jira LE-4321
cve CVE-2025-38718
Rebuild_History Non-Buildable kernel-4.18.0-553.77.1.el8_10
commit-author Xin Long <[email protected]>
commit fd60d8a

A cloned head skb still shares these frag skbs in fraglist with the
original head skb. It's not safe to access these frag skbs.

syzbot reported two use-of-uninitialized-memory bugs caused by this:

  BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211
   sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211
   sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998
   sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88
   sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331
   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122
   __release_sock+0x1da/0x330 net/core/sock.c:3106
   release_sock+0x6b/0x250 net/core/sock.c:3660
   sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360
   sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885
   sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031
   inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851
   sock_sendmsg_nosec net/socket.c:718 [inline]

and

  BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987
   sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987
   sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88
   sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331
   sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148
   __release_sock+0x1d3/0x330 net/core/sock.c:3213
   release_sock+0x6b/0x270 net/core/sock.c:3767
   sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367
   sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886
   sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032
   inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851
   sock_sendmsg_nosec net/socket.c:712 [inline]

This patch fixes it by linearizing cloned gso packets in sctp_rcv().

Fixes: 90017ac ("sctp: Add GSO support")
	Reported-by: [email protected]
	Reported-by: [email protected]
	Signed-off-by: Xin Long <[email protected]>
	Reviewed-by: Marcelo Ricardo Leitner <[email protected]>
Link: https://patch.msgid.link/dd7dc337b99876d4132d0961f776913719f7d225.1754595611.git.lucien.xin@gmail.com
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit fd60d8a)
	Signed-off-by: Jonathan Maple <[email protected]>

jira LE-4321
Rebuild_History Non-Buildable kernel-4.18.0-553.77.1.el8_10
commit-author Faicker Mo <[email protected]>
commit 0bdc924

The unexpected MPLS packet may not end with the bottom label stack.
When there are many stacks, The label count value has wrapped around.
A dead loop occurs, soft lockup/CPU stuck finally.

stack backtrace:
UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26
index -1 is out of range for type '__be32 [3]'
CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G           OE   5.15.0-121-generic #131-Ubuntu
Hardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021
Call Trace:
 <IRQ>
 show_stack+0x52/0x5c
 dump_stack_lvl+0x4a/0x63
 dump_stack+0x10/0x16
 ubsan_epilogue+0x9/0x36
 __ubsan_handle_out_of_bounds.cold+0x44/0x49
 key_extract_l3l4+0x82a/0x840 [openvswitch]
 ? kfree_skbmem+0x52/0xa0
 key_extract+0x9c/0x2b0 [openvswitch]
 ovs_flow_key_extract+0x124/0x350 [openvswitch]
 ovs_vport_receive+0x61/0xd0 [openvswitch]
 ? kernel_init_free_pages.part.0+0x4a/0x70
 ? get_page_from_freelist+0x353/0x540
 netdev_port_receive+0xc4/0x180 [openvswitch]
 ? netdev_port_receive+0x180/0x180 [openvswitch]
 netdev_frame_hook+0x1f/0x40 [openvswitch]
 __netif_receive_skb_core.constprop.0+0x23a/0xf00
 __netif_receive_skb_list_core+0xfa/0x240
 netif_receive_skb_list_internal+0x18e/0x2a0
 napi_complete_done+0x7a/0x1c0
 bnxt_poll+0x155/0x1c0 [bnxt_en]
 __napi_poll+0x30/0x180
 net_rx_action+0x126/0x280
 ? bnxt_msix+0x67/0x80 [bnxt_en]
 handle_softirqs+0xda/0x2d0
 irq_exit_rcu+0x96/0xc0
 common_interrupt+0x8e/0xa0
 </IRQ>

Fixes: fbdcdd7 ("Change in Openvswitch to support MPLS label depth of 3 in ingress direction")
	Signed-off-by: Faicker Mo <[email protected]>
	Acked-by: Ilya Maximets <[email protected]>
	Reviewed-by: Aaron Conole <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Paolo Abeni <[email protected]>

(cherry picked from commit 0bdc924)
	Signed-off-by: Jonathan Maple <[email protected]>

jira LE-4321
cve CVE-2025-37797
Rebuild_History Non-Buildable kernel-4.18.0-553.77.1.el8_10
commit-author Cong Wang <[email protected]>
commit 3df275e

This patch fixes a Use-After-Free vulnerability in the HFSC qdisc class
handling. The issue occurs due to a time-of-check/time-of-use condition
in hfsc_change_class() when working with certain child qdiscs like netem
or codel.

The vulnerability works as follows:
1. hfsc_change_class() checks if a class has packets (q.qlen != 0)
2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g.,
   codel, netem) might drop packets and empty the queue
3. The code continues assuming the queue is still non-empty, adding
   the class to vttree
4. This breaks HFSC scheduler assumptions that only non-empty classes
   are in vttree
5. Later, when the class is destroyed, this can lead to a Use-After-Free

The fix adds a second queue length check after qdisc_peek_len() to verify
the queue wasn't emptied.

Fixes: 21f4d5c ("net_sched/hfsc: fix curve activation in hfsc_change_class()")
	Reported-by: Gerrard Tai <[email protected]>
	Reviewed-by: Konstantin Khlebnikov <[email protected]>
	Signed-off-by: Cong Wang <[email protected]>
	Reviewed-by: Jamal Hadi Salim <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit 3df275e)
	Signed-off-by: Jonathan Maple <[email protected]>

jira LE-4321
cve CVE-2025-37797
Rebuild_History Non-Buildable kernel-4.18.0-553.77.1.el8_10
commit-author Cong Wang <[email protected]>
commit 6ccbda4

Similarly to the previous patch, we need to safe guard hfsc_dequeue()
too. But for this one, we don't have a reliable reproducer.

Fixes: 1da177e ("Linux-2.6.12-rc2")
	Reported-by: Gerrard Tai <[email protected]>
	Signed-off-by: Cong Wang <[email protected]>
	Reviewed-by: Jamal Hadi Salim <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit 6ccbda4)
	Signed-off-by: Jonathan Maple <[email protected]>

Rebuild_History BUILDABLE
Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50%
Number of commits in upstream range v4.18~1..kernel-mainline: 567757
Number of commits in rpm: 12
Number of commits matched with upstream: 6 (50.00%)
Number of commits in upstream but not in rpm: 567751
Number of commits NOT found in upstream: 6 (50.00%)

Rebuilding Kernel on Branch rocky8_10_rebuild_kernel-4.18.0-553.77.1.el8_10 for kernel-4.18.0-553.77.1.el8_10
Clean Cherry Picks: 4 (66.67%)
Empty Cherry Picks: 2 (33.33%)
_______________________________

Full Details Located here:
ciq/ciq_backports/kernel-4.18.0-553.77.1.el8_10/rebuild.details.txt

Includes:
* git commit header above
* Empty Commits with upstream SHA
* RPM ChangeLog Entries that could not be matched

Individual Empty Commit failures contained in the same containing directory.
The git message for empty commits will have the path for the failed commit.
File names are the first 8 characters of the upstream SHA